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ABSTRACT 



An open network system for supporting input/output (I/O) 
operations for non-standard I/O devices are disclosed. The 
system includes a server coupled to a plurality of I/O device 
through an open network and an extended open system 
protocol that supports communication with devices that are 
not personal computers (PCs). These devices include mag- 
netic stripe readers, check readers, smart card readers, credit 
card terminals, screen phone terminals, PIN pads, printers, 
and the like. The extended open network protocol includes 
tags which identify device and input operations and 
attributes which identify the location, data exchange 
method, and data variable names for the retrieval, 
acquisition, and submission of data between the server and 
I/O devices. Preferably, the open network protocol is imple- 
mented in a Hyper Text Transport Protocol (HTTP). 
Preferably, the system includes a common gateway interface 
(CGI) at the server which converts protocol statements 
communicated between the server and I/O devices to appli- 
cation language statements for providing data to an appli- 
cation program coupled to the server. Most preferably, the 
application statements and protocol statements are con- 
structed in integrated statements with an editor. The editor 
ensures that data identifiers in the application and protocol 
statements are compatible. The integrated statements are 
then parsed by the editor to segregate the protocol state- 
ments from the application statements. Hie protocol state- 
ments are downloaded in a file to a client program at an I/O 
device for processing. The application statements are stored 
in a file for use by the application. In this manner, generation 
of the files for client and application processing are auto- 
matically done without the user ensuring the correlation of 
the data fields in the two files. 

18 Claims, 25 Drawing Sheets 
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HTML+DAttributes 



<FORM ACTION' 



METHOD' 



."uri" 

FROM "file name" 
70 PRINTS! 
TO "file name" 
FROM SCR 
JO SCR 

"GET" 

TOST" 

"RHYMBfT" 



Description 



To/From Webserver URL 
From Terminal Local File 
To Local Printer 
To Terminal Local File 
From Smart Card Reader 
To Smart Card Reader 

Retrieve Data 
Store Data 

Directive to deliver INPUT data to 
a private Payment Network for 
authorization and settlement 



SQL <databasename> SQL statement database table 



Attribute 



<INPUTTYPE» 



NAME- 
\ALUE- 
CHECKED- 
SIZE- 

MAXLENGTH- 



Value 

"text" 

"password" 

"checkbox" 

"radio" 

"submit" 

"reset" 

<fiekJname> 

<initialvalue> 



Description 



Attribute HTML+DVfalue Terminal Device 



TYPE- 



NAME- 



"MSRTr 
"MSRT2" 
"KEY" 
W 
"BOAT 
"MICR" 
"AMT" 
"NT 
"LOCAL" 

"AUTOSUBMT" Submit FORM to ACTION URL 



Mag Stripe Reader- Track 1 
Mag Stripe Reader - Track 2 
Terrninal Command Keypad 
PIN Pad 

Bar Code Wand 
Check MICR Reader 
Dollar amount key input mask 
Integer key input mask 
Input from Local variable 



ip_address 

nostohone 

tid 

workjcay 

datetime 

deposit_acct 



Local variable - Terminal's P Address 

Local Variable-Local Internet Access Phone Number 

Local variable - Terrninal ID 

Local variabte-PINencryption working key 

Local variable -Date and tore 

Local Variable-Merchant Deposit Account 

FIC.2 
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SQL Statements 

The following SQL commands represent a subset of the entire command 
set that varies by database vendor. 



HTML+P Attributes 
SELECT*, fiekLname,- 



FROM-<table name>^ 

WHERE-<conctition> 

name -"constant" 
name LIKE "constant" 
name ISI "constant" 
AND 
OR 

ORDERmASC 
DESC 
2 

GROLP-<name> 



Description 

Request field jiame (one or many) 
from a database table 
Database table name 
Conditional selection of data 



Request in ascending order 

-descending 

~by2's 



INSBTT TABLE-<table name> 
WLUES-'constants" 



Insert new data in database table 



UPDATEmOM 

<t9blenBrno> 

SET-fiekl_name-"constanf' 
I WHERB*<condition> ] 



Update fiekLname indatabase table 
Update if WHfflE clause is satisfied 



DBJETEFROM<tabbname> 
lWHEREr<CQnditk>n>1 



Delete all columns that satisfy 
WHREclause 



CREATE TABLE<tabh_name> 
PRIMARY KEY<name> 



Create database table 



FIG.* 
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IDLE 





100 



OPEN 
REMOTE URL 





102 


CONNECT TO 
SERVER 




x 106 


REC 
HTMt 


EIVE 
.FILE 



108 



NO 



OPEN 
LOCAL URL 





104 


READ H 
IDENTIFII 
FROM LOC 


TML FILE 
ED BY URL 
AL MEMORY 



772 



PROCESS 
HTML FILE 




YES 



STORE 

HOI 


UNDER 
'KEY 




YES 

* - 


STORE HTML FILE 
IN LOCAL MEMORY 



NO 



120 



FIC.4 
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1 



SCAN HTML FILE 
FOR TAG 




NO 



YES 



YES 



PROCESS 
STANDARD TAG 



752 



BLOCK 114 
FIG4 



PROCESS FORM 
TAG 



148 



PROCESS INPUT 
TAG 



FIG.9 



750 



BLOCK 140 
FIG5 



SCAN FOR 
ATTRIBUTE 




PROCESS ACTION 
ATTRIBUTE 



765 



PROCESS METHOD 
ATTRIBUTE 

170 
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BLOCK 160 
FIG 6 



NO 



YES 



SCAN FOR 
ACTION 




208 



'ACTON = FROM 
<FILE> 

'no 



ACTION = TO 
PRINTER 

V 182 
NO 



YES 



YES 



READ DATA FROM 
LOCAL <FILE> 



196 



SEND DATA TO 
PRINTER 



198 



ACTION = TO 
<FILE> 
7 ^ 184 



YES 



WRITE DATA TO 
LOCAL <FILE> 



200 



ACTION = TO 
SCR 

NO 



ACTIONS FROM 
SCR 



NO 



YES 



YES 



WRITE DATA 
TO SMART CARD 



202 



READ DATA FROM 
SMART CARD 
READER 



204 



ACTION^ URL 
<F1UB> 



192 



YES 



PROCESS 

STANDARD URL 

< FILE> ASSIGNMENT! 
=^ 

194 



FIC.7 
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210 



NO 



YES 



QUERY URL 
<FILE> WITH DATA 



226 



NO 



212 



YES 



POST DATA TO 
URL <FILE> 



229 



NO 



METHOD* 
FWYMENT 
? 



NO 



2W 



224 



BLOCK 160 
FIG6 «— 



YES 



YES 



PASS SQL FILE 
IDENTIFIER 



230 



PROCESS 
PAYMENT 
COMMAND 



232 



NO 




FIG.8 
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SCAN FOR 
ATTRIBUTE 

1 V. — 1 

250 



BLOCK 140 
FIG 5 




STANDARD HTML 
INPUT ATTRIBUTES 



262 



FIG. 9 
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TYPE = 
MSRT1 

NO 

1YPE=" 
MSRT 2 

NO 



NO 

"TYPE^ 
PIN 

NO 

BCW 
NO 



MICR 

9 



NO 



INT 



NO 



LOCAL 

'no 

"TYPE** 
^ALfTOSUB^ 



NO 



YES 



YES 



272 



YES 



274 



YES 



276 



278 



YES 



252 



YES 



284 



YES 



255 



READ MSRT 1 



290 



READ MSRT 2 -* 



292 



READ KEY PAD 



294 



READ PIN 



296 



YES 


READ BAR CODE 




READER 



298 



READ CHECK 
READER 



300 



READ DOLLAR 
AMOUNT VIA MASK 



302 



READ NUMBER 
VIA MASK 



304 



YES 


READ LOCAL 




VARIABLE 



306 



PROCESS 
AUTOSUBMIT 



308 



FIG. 10 



PROCESS 
STANDARD HTML 
INPUT TYPE 



310 




BLOCK 250 
FIG 9 



03/16/2004, EAST Version: 1.4.1 



U.S. Patent Apr. 2, 2002 Sheet 10 of 25 US 6,366,967 Bl 




PROCESS 
STANDARD TAG 



^ ' 

336 



FiC.11 
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1. <FORMACTION=URL METHOD* GET> 

2 <FORMACTION=URL METHOD= POST> 

3. <FORM ACTION=URL METHOD* SQL <database_name> 



FIG. 12 




FIC.17A 

<FORMACTION=<filename> METHOD=PAYMENT> 

<INPUT TYPE=AUTOSUBMIT> 

</FORM> 

FIC.15B 



<FORM ACTION=dsinet METHOD=PAYMENT> 

<INPUT TYPE=LOCAL NAME=DEPOSIT_ACCT VALUE=1 23456890234567890 

<INPUT TYPE=AUTOSUBMIT> 

</FORM> 

FIC.17C 
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1.a. Transaction Request HTML+D 

<HTML> 500 
<BOOY> 

<FORM ACTION=tibase URL 
METHOD=SQL 
"BEGIN TRAN 

IF NOT EXISTS ( SELECT substring(account 1 , 20) FROM auth table) 
BEGIN 

INSERT TABLE=togLtable VALUES=(getdateO,tid, substring (account 120) . 

substring( account, 22, 4), amount) 

SELECT * FROM log table WHERE trandate = getdate() 

END 

ELSE SELECT* FROM errorjable WHERE error no=1 

COMMIT TRAN"> 
<INPUT TYPE=10CAL" NAME=W» 
ENTER ACCOUNT NUMBER 
<INPUT TYPE= , 'MSRT2" SIZE=40 NAME=account> 
ENTER AMOUNT 

<INPUT TYPE="AMT S1ZE=8 NAME=amount> 

<INPUT TYPE^AUTOSUBMIT* 

<FORM> 

</BOOY> 

</HTML> 



lb. Transaction Accepted Response 
<HTML> 510 



<BODY* 

<FORM ACTI0N=7O PRINTER METHOD«POST> 
JUNE 11995 1Q30AM PURCHASED 

TERMINAL ID: 999999999</P> 
ACCOUNT NUMBER 99999999999999999999<P> 
EXP DATE 99/99</P> 
AMOUNT $9999j99</P> 
AUTH NUMBER 999999999s/P> 
<fip> 

</p> 

CUSTOMER SIGNATURE </b> 

<FORM> 

AFPROVEO fl0000000X) <^ 

<IBOCff> 

</HTML> 

I.e. Transaction Declined or Submit Error Response 

<HTML> Ks2 ° 
<8QOf> 

DECLINELXMESSAGE> 

^BODY* 

</HTML> 

FIG. 14 



03/16/2004, EAST Version: 1.4.1 



U.S. Patent Apr. 2, 2002 Sheet 13 of 25 US 6,366,967 Bl 



2.a. Transaction Request HTML+D 

<HTMl> 550 
<BODY> 

<FORM ACTIOM=dbase URL 
METHOD=SQJL"BEGIN TRAN 

IF NOT EXISTS ( SELECT substring(account 1 . 20) FROM authjable) 

BEGIN 

INSERT TABLE=log_table VALUES=(getdate().tld, substring! account. 1,20). 
substring! account 22, 4), amount) 

END 

ELSE BEGIN 

SELECT * FROM error table WHERE error no=1 
RETURN 

END 

INSERT TABLE=order_table VALUES=( getdate(). cijstjiame.address.city state, zip, 
partjcode, unit _price. tax, shipjnethod, ship.chrg, unit_price + tax + 
ship.chrg. substring! account 1. 20) .substring! account 22, 4)) 

SELECT * FROM order table WHERE trandate = getdate!) 

COMMIT TRAN"> 
CUSTOMER NAME 

<INPUTTYPE=TEXTSIZE=30 NAME=^_name></p> 
ADDRESS: 

<INPUTTYPE='TEXT SEE=40 NAVt=acWress><p> 
CITY 

<WPUTTYPE=TEXr SEE=a) NAME=*atyxp> 
STATE 

<MPUT TYPE=TEXr SIZE=2 NAME=stat0> 

ZIR 

<INPUTTYPE=nEXT SEE=10 NAME^acldress><p> 
SCAN FART CODE 

<INPUT TYPE="BCW SIZE=9 NAME=part_codBX^> 
ENTER UNTT PRICE 

<NFlTTTYPE^A\^SIZE^NAVE=unit jxicex^> 
TAX 

<INPUTTYPE=^^SEE^NAME=tax>^p> 
SHIPPIMG METHOD: 

<INPUTTYPE^TEXr SEE«10 NAME^_method>^p> 
SHIPPING AMOUNT: 

<INPUT TYPE^AMT SEE=«5 NIAME*^_chrg>«^> 
SUOECARO. 

<1NPUTTYPE=TVBRTZSI2E^NWME=gccxxrt?^ 

<INPUTTYPE= M SUBVir> 

</FORM> 

</&XH> 

<HTML> 



FIG.15A 
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2.b. Transaction Accepted Response 

<HTML> 555 
<800Y> 

<FORM ACTION=TO PRINTER METHOD=POST> 
ORDER # 9999999999 APPROVED^ 
JUNE 1 1995 1&30AM PURCHASED 
TERMINAL ID: 999999999<P> 

NA^xxxxxxxxxxxxxxxxxx»o<xxxxxxxxxxm</p> 

ADDRESS:</p> 

XXXXXXXXXX>OOO0O(XXXXXXX)0OO0OO00O0<XXXXXX</p> 
CrTYXXXXXXXXXXXXXXXXXXXXXX>CKX<^ 
STATE XX 2PXXXXXXXXXX<^y> 
ACCOUNT NUMBER 99999999999999999999<fa> 
EXP DATE 99Wd> 
FART CODE 9999999994p> 
UNIT PRICE $9999S9^> 
SHIP METHOQXXXXXXX CHARGE p9999<fa> 
TOTAL AMOUNT: $9999S9<p> 
AUTH NUMBER 999999999^p> 
<^p> 

<jp> 

CUSTOMER SIGNATURE^ 

<tf=ORM> 
<IBOUf> 
<MWL> 



Zc. Transaction Declined or Submit Error Response 

<HTML> 560 
<800Y* 

DEaiNED<errorcode> 

<QOOf> 

<HTML> 



FIG.15B 
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3.a. Transaction Request HTML+D 

<HTML> 
<BODY> 

<FORM ACTION=dbase_URL 
METHOD SQL 

"INSERT TABLE=order_table VALUES=( getdateQ, cust_name.aclclress.city state, zip. 
partjcode, unit_price, tax, ship_method, ship_chrg,unit_price + tax + 
shipjchrg, substring( account 1. 20) .substring( account 22, 4)) 
SELECT * FROM order table WHERE trandate = getdate()"> 
<INPUTTYPE-"LOCAL" NAME=tid> 
CUSTOMER NAME 

<INPUT TYPE=TEXT" SIZE=30 NAME=cust nameXp> 
ADDRESS: 

<INPUT TYPE= M TEXT SIZE=40 NAME=addressx/p> 

CITY: 

<INPUT TYPE-TEXT SIZE=20 NAME=cityxp> 
STATE 

<INPUT TYPE=TEXT SIZE=2 NAME=state> 
ZIP: 

<INPUTTYPE='TEXr SIZE=10 NAME=addressx/p> 
ENTER PART CODE 

<INPUT TYPE-TEXT* SIZE=1 0 NAME=part codex/p> 
ENTER UNIT PRICE: 

<INPUTTYPE="AMT SIZE=8 NAME=unit _pricex/p> 
TAX 

<INPUT TYPE="AMT" SIZE=5 NAME=taxx/p> 
SHIPPING METHOD: 

<INPUTTYPE="TEXT SIZE=10 NAME=ship_methodXp> 
SHIPPING AMOUNT: 

<INPUT TYPE» M AMT SIZE=5 NAME=ship_chrgx/p> 

<INPUT TYPE="SUBMir > 

</FORM> 

</BODY> 

</HTML> 
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3.b. Transaction Accepted Response 

<HTML> 
<BODY> 

<FORM ACTIONNTO PRINTER METHOD=POST> 

ORDER # 9999999999 APPROVED</p> 

JUNE 11995 103QAM PURCHASED 

TERMINAL ID: 999999999</P> 

NAWEXXXXXXXXXXXXXXXXXXXXX)000<XX)COOOOO<</p> 

ADDRESS:</p> 

xxx>oooooc<x>o<xxxxxx>ooooooo<xxxxxxxxxxxxx</p> 

CITY XXXXXXXXXXXXXXXXXXXXXXXXXXX</p> 
STATE XX ZIRXXXXXXXXXX</p> 
PART CODE: 999999999</p> 
UNIT PRICE $9999.99</p> 
SHIP METHODXXXXXXX CHARGE !>9999.99</p> 
TOTAL AMOUNT: $9999.99</p> 
</FORM> 

<FORM ACTION*<file name> METHOD=PAYMENT> 

<INPUT TYP£=AUTOSUBMIT> 

</FORM> 

</BODY> 

</HTML> 



3.c. Transaction Declined or Submit Error Response 

<HTML> 
<BODY> 

DECLINED <errorcode> 

</BODY> 

</HTML> 
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4.a. Transaction Request HTML+D 

<HTML> 
<BODY> 

<FORM ACTION=SCR1 METHOO=POST> 
<INPUTTYPE="LOCAL" NAME=tk> 
SLIDE CARD: 

<INPUTTYPE="MSRT2" SEE=40 NAME=track2> 
ENTER AMOUNT: 

<INPUTTYPE= 4, AMr' S1ZE=8 NAME=amount> 

<INPUTTYPE="LOCAL" NAME=work_key> 

<INPUT TYPE="AUTOSUBMrr> 

</FOPM> 

</BODY> 

<HTML> 



4Ji Transaction Accepted HTML+D 

<HTML> 
<BODY» 

<FORM ACTION=TO PRINTER METHOO=POST> 
DATE-99^99 TIME9999A</P> 
ACCOUNT NUMBER 99899999999899889989«b> 
EJPDATE 9999<^» 
AMOUNT: $999&99<fc> 
AUTH NUMBER 999999999</p> 
<FORM> 

APPROVED9999999994P> 

«BODY> 

<vHTML> 



4.c. Transaction Declined or Submit Error Response 

<HTML> 
<BOOf> 

DECLINED <errorcode> 

<BOOY> 

</KTML> 
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5.a. Transaction Request HTML+D 

<HTML> 
<BODY> 

<FORM ACTION=SCR2 METHOD=POST> 
<INPUT TYPE= M LOCAL" NAME=tid> 
ENTER PIN: 

<INPUT TYPEa-FASSWORD" SIZE=4 NAME=pin> 
ENTER AMOUNT: 

<INPUT TYPE*"AMT SIZE=8 NAME=arnount> 

<INPUT TYPE="LOCAL" NAME=wofk key> 

<INPUT TYPE="AUTOSUBMrr> 

</FORM> 

</BODY> 

</HTML> 



5h Transaction Accepted HTML+D 



<HTML> 
<BODY> 

<FORM ACTION=TO PRINTER METHOD=POST> 
QATE-9&99/99 TIME9999A</P> 
ACCOUNT NUMBER 9999999999999090000i)<P> 
EXP DATE 99/99</P> 
AMOUNT $9999.99«^P> 
AUTH NUMBER 999999999</P> 
</FORM> 

APPR0VEO999999999<7P> 

<BODY> 

<HTML> 



5.c Transaction Declined or Submit Error Response 

<HTML> 
<BOOY> 

DECUNED<errorcode> 

<BODY> 

<HTML> 
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6.a Transaction Request HTML+D 

<HTML> 
<BODY> 

<FORM ACTION=host URL METHOD=POST> 
<INPUT TYPE="LOCAL" NAME=tid> 
SLIDE CARD 

<INPUT TYPE="MSRT2" SIZE=40 NAME=track2> 
^NPUTTYPE^PIN" SIZE=4 NAME=pin> 
ENTER AMOUNT: 

<INPUT TYPE="AMT S1ZE=8 NAME=amount> 

<INPUT TYPE="AUTOSUBMir> 

<FORM> 

</BODY> 

</HTML> 



6.b. Transaction Accepted HTML+D 

<HTML> 
<BODY* 

<FORM ACTION=TO PRINTER METHOD=POST> 

DATE99/99/99 TIME9999A</P> 

TERMINAL ID: 999999999</P> 
ACCOUNT NUMBER 99999999999909000000<P> 

EXP DATE 99/99«P> 

AMOUNT $9999.99</P> 

AUTH NUMBER 999999999</P> 
</FORM> 

APPROVEDS99990999^P> 

</BODY> 

<HTML> 



6.c. Transaction Declined or Submit Error Response 

<HTML> 
<BODY* 

DECUNED<errorcode> 

<INPUT TYPE="LOCAL" NAME=work_key VALUE="9999999999999999"> 

<BODV> 

</HTML> 
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7.a. Transaction Request HTML+D 

<HTML> 
<BQUf> 

<FORM ACTION=dbase_URL 
METHOI>SQL 

"IF EXISTS ( SELECT account FROM check table) 

SELECT * FROM check table WHERE account = DDAaccount 
ELSE SELECT * FROM errorjable WHERE error_no=1 "> 
<INPUT TYPE="LOCAL" NAME=tid> 
SCAN CHECK: 

ONPUT TYPE="MICR" SlZE=20 NAME=account> 
ENTER AMOUNT 

<INPUT TYPE="AMT SlZE=8 NAME=amount> 

<INFUT TYPE="AUTOSUBMir> 

</FORM> 

</BODY> 

</HTML> 



7.b. Transaction Accepted Response 

<HTML> 
<BODY> 

<FORM ACT)ON=TO PRINTER METHCO=POST> 
DATE999999 T1ME9999</P> 
TERMINAL IO 99999000CK /P> 
ACCOUNT NUMBER 999999999999999999994P> 
AMOUNT $999959<VP> 
AUTH NUMBER 999999999<P> 
<rt=ORM> 

APPROVEQ999999999<yP> 

<BODt> 

<HTML> 



7.a Transaction Declined or Submit Error Response 

<HTML> 
<SOCtt> 

DECLINED <er ror ccde> 

</BOOY> 

</HTML> 



FIC.19 



03/16/2004, EAST Version: 1.4.1 



U.S. Patent Apr. 2, 2002 Sheet 21 of 25 US 6,366,967 Bl 



8.a. Transaction Request HTML+D 

<HTML> 
<BODY> 

<FORM ACTlOWbase URL 
METHOD=SQL 

* BEGIN TRAM 

IF NOT EXISTS ( SELECT sub6tring(aDccurt51 20)FROWauth_table) 
BEGIN 

SELECT cur_ba!FROMcust tblWHEREsuhs«ing(aocxut51 ,20>=acoounl 

SELECT amount = amourt~( points / .01 J 

SELECT cur bd=cur bal+( amount* jOI ) 

UPDATE TABL&custTbl VALUES=( geidateC account cur_bal - ports ) 

subs&t^aosourC^ 4), amount) 
END 

ELSE SELECT* FROM error tabte WHERE error_no=1 " 

COMMIT TRAN"> 
<INPUT TYPE="LOCAL" NAME=tid> 
ENTER ACCOUNT NUMBER: 
<INPUT TYPE S "MSRT1 SIZE=90 NAME=account> 
ENTER AMOUNT 

<INPUT TYPE="AMT SIZE=8 NAME=amount> 
REDEEM POINTS? 

<INPUT TYPE="INT SIZE=6 NAME=points> 

<INPUT TYPE="AUTOSUBMIT"> 

</FORM> 

</BODY> 

</HTML> 

8.b. Transaction Accepted Response 

<HTML> 
<BODY> 

<FORM ACT10N=TO FWNTERMETH0p4^0ST> 
JUNE 1 1996 103QAM PURCHASER 

TERMINAL ID: 99999p0gp ^P> 

ACCOUNT NUMBER 999999999999999999&tf* 
EXP DATE 9999</P> 
AMOUNT 
AUTH NUMBER 

Ht <^ 

CUSTOMER SIGNATURE^ 

<fp> 

Saxxxw^^ 

POINTS REDEEMED 9S»993*fo> 
POINTS EARNED: 999999<A)> 
CURRENTPOINT BALANCE 999999<fo> 
<FORM> 

APPROVEDS99999999<P> 
<«ODY> 
<AfFML> 

8.c Transaction Declined or Submit Error Response 

<HTML> 
<800Y> 

DECLINED <WESSAGE> w-n*> 

<BODY> FIG. 20 
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9.a Transaction Request HTML+D 

<H7M> 
<8O0Y* 

<FORM ACTION=dbase URL 
METHOD=SQL~ 



"SELECT fields FROM table WHERE condition^ 



<INPUT TYPE=tOCAL" NAME=tid> 

ENTER SEARCH TABLE NAME 

<1NPUT TYPE=TEXT SIZE=10 NAME=tabte> 

ENTER SEARCH FIELD NAMES 

<INPUTTYPE=*TEXT SIZE=100 NAME*fieids> 

ENTER SEARCH CONDITION: 

<INPUT TYPE=TEXT SIZE=50 NAME=condition> 

<INPUT TYPE="AUTOSUBMTr> 

<FORM> 

<iBOCH> 

<HTML> 



9.b. Transaction Response 

<HTML> 
<BO0h> 

<FORM ACTION=TD PRINTER METHOOPOST^ 
FIELD1 FIELD2 RELD3 ~~ FIELDN </p> 



xxxxx xxxxx xxxxx 
xxxxx xxxxx xxxxx 



</p> 

XXXXX </p> 
XXXXX <Jp> 



XXXXX XXXXX xxxxx 



XXXXX <^p> 



<FORM> 
<*BOOY> 
<fl-fTML> 



FIG.21 
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1 0.a. Transaction Request HTML+D 

<HTML> 
<BODY> 

<FORM ACTION=dbase URL 
METHOD=SQL 

* INSERT TABLE=log_table VALUES=( getdate(). tid, gross_sa!es, opn_chks, voids, 
emp disc mgr disc, vip card, man over, coupons, salesjax. c_dep1, c_dep2, 
c_dep3, c_dep3, crig_fund,cc_dep,'batch_na chrgjsales, paidjouts, cojsales. 
cc sales, te sales, gross sales - opn_chks - voids - emp_disc - mgr_disc - vip_card- 
mah over - coupons - safesjax, gross_sales - opn_chks - voids - 
emp'disc - mgr disc - vip_card - man over - coupons - c_dep1 - c r dep2 - 
c dep3 - c dep4 - chgfund - cc dep - batch_no - chra sales - paid.outs) 
SlLECT * FROM loa table WHERE trandate » getdate()"> 

<INPUT TYPE= u LOCAL" NAME*tk> 

ENTER GROSS SALES: 

<INPUT TYPE="AMT SIZE=8 NAME=gross_sales> 
ENTER OPEN CHECKS: 
<INPUT TYPE="INT" SIZE-7 NAME=opn chks> 
ENTER VOIDS: 

<INPUT TYPE="INT SIZE=7 NAME=volds> 

ENTER EMP DISCOUNTS: 

<INPUT TYPE="INT" SIZE=7 NAME=emp_diso 

ENTER MGR DISCOUNT: 

<INPUT TYPE-'INT SIZE=7 NAME=mgr_disO 

ENTER VIP CARD: 

<INPUT TYPE a "INT SIZE=7 NAME=vip_card> 
ENTER MANUAL OVERRINGS: 
<INPUT TYPE=1NT" SIZE=7 NAME=man_over> 
ENTER COUPONS: 

<INPUT TYPE="INr SIZE=7 NAME=coupons> 
ENTER SALES TAX: 

<INPUTTYPE="AMT" SIZE=8 NAME=salesJax> 

ENTER CASH DEPOSIT 1: 

<INPUT TYPE="AMT SIZE=8 NAME=c_dep1> 

ENTER CASH DEPOSIT 2 

<INPUTTYPE«"AMT SIZE=8 NAME=c_dep2> 

ENTER CASH DEPOSIT 3: 

<INPUT TYPE="AMT SIZE=8 NAME=c_dep3> 

ENTER CASH DEPOSIT 4: 

<INPUT TYPE="AMT SIZE=8 NAME=c_dep4> 

ENTER CHANGE FUND: 

<INPUT TYPE="AMT" SIZE-8 NAME=chg_fund> 
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ENTER CC DEPOSIT: 

< INPUT TYPE="AMT SIZE=8 NAME*cc_dep> 
ENTER BATCH #: 

< INPUT TYPE-' INT" SIZE=3 NAME=batch no> 
ENTER CHARGE SALES: 
< INPUT TYPE="AMT" SIZE=8 NAM E= chrg sales> 
ENTER PAID OUTS: 

<INPUT TYPE= M INT" SIZE=8 NAME=paid_outs> 

ENTER CARRY OUT SALES: 

<INPUT TYPE="AM"H SIZE=8 NAME=CO_sales> 

ENTER CREDIT CARD SALES: 

<INPUT TYPE= U AMT SIZE=8 NAME=cc sales> 

ENTER TAX EXEMPT SALES: 

<INPUT TYPE="AM"P SIZE=8 NAME=te_sales> 

<INPUT TYPE="AUTOSUBMIT"> 

</FORM> 

</BODY> 

</HTML> 

10.b. Transaction Response 

<HTML> 
<BODY> 

<FORM ACTION=TO PRINTER METHOD=POST> 



10:30AM 



JUNE 1 1995 
TERMINAL ID: 
GROSS SALES 
VOIDS 

EMP DISCOUNTS 
MANAGER DISCOUNTS 
VIP CARD 
COUPONS 

MANUAL OVERRINGS 
SALES TAX 
CASH DEPOSIT 1 
CASH DEPOSIT 2 
CASH DEPOSIT 3 
CASH DEPOSIT 4 
CASH DEPOSIT 5 
CHANGE FUND 
CC DEPOSIT 
CHARGE SALES 
PAID OUTS 
CARRY OUT SALES 
CREDIT CARD SALES 
TAX EXEMPT SALES 



DAILY REPORT</P> 
999999999</P> 
999999.99</P> 
99 99999.99</P> 
99 99999.99</P> 
99 99999.99</P> 
99 99999.99</P> 
99 99999.99</P> 
99 99999.99</P> 
999999.99</P> 
999999.99</P> 
999999.99</P> 
999999.99<P> 
999999.99</P> 
999999.99</P> 
999999.99</P> 
999 999999.99<P> 
999999.99</P> 
99 99999.99<P> 
999999.99<P> 
999999.99</P> 

999999.99<P> 
</p> 



NET SALES 

OVER/SHORT 

</FORM> 

</BODY> 

</HTML> 



9999999<P> 
9999999<P> 
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11. a. Transaction Request HTML+D 

<HTML> 
<BODY> 

<FORM ACTION=MAILTO:mail_to> 
ENTER MAIL ADDRESS: 
<INPUT TYPE»"TEXT SIZE=20 NAME=mail to> 
ENTER MESSAGE: 
<INPUTTYPE=-TEXT SIZE*100> 
<INPUT TYPE="AUTOSUBMIT"> 
</FORM> 
</BODY> 

FIG.2* 
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OPEN NETWORK SYSTEM FOR I/O 
OPERATION INCLUDING A COMMON 
GATEWAY INTERFACE AND AN EXTENDED 
OPEN NETWORK PROTOCOL WITH NON- 
STANDARD I/O DEVICES UTILIZING 
DEVICE AND IDENTIFIER FOR 
OPERATION TO BE PERFORMED WITH 
DEVICE 

This application is a continuation of application Ser. No. 
08/995,123 filed Dec. 19, 1997 (now U.S. Pat. No, 5,905, 
908), which is a continuation of application Sen No. 08/493, 
772 filed Jun. 22, 1995 (now U.S. Pat. No. 5,742,845). 

FIELD OF THE INVENTION 

This invention relates to data transaction systems, and 
more particularly, to data transaction systems using non- 
standard input/output devices. 

BACKGROUND OF THE INVENTION 

Data transaction systems which communicate with a 
plurality of remote terminals to transfer information used to 
complete a transaction or compile a database are well 
known. Typically, such systems include a central transaction 
processing system which may maintain a database of infor- 
mation such as customer or consumer data. Exemplary 
information in such a database may include customer 
identification, customer account numbers, credit limits and/ 
or account balances from which a customer may draw. The 
central transaction processing system is typically coupled to 
a plurality of remote transaction or data input terminals. 
Transaction computers may include special purpose devices 
such as automatic teller machines (ATMs), point of sale 
(POS) terminals, credit card terminals, and screen phone 
terminals. Screen phone terminals are devices which inte- 
grate a telephone with an ATM-like device and possibly a 
magnetic card swipe reader. Data input terminals may 
include personal computers (PCs) interfaced to data collec- 
tion devices or special purpose data collection terminals or 
monitors. 

In these known data transaction systems, a user usually 
initiates a transaction by requesting access to funds in an 
account or from a credit line maintained by the central 
processing system. The request is transmitted to the central 
processing system which performs a verification to deter- 
mine whether the user is a valid user of the system, has an 
account within the system, and that the amount of the 
transaction is within the limits of the consumer's credit line 
or that the user has the requested funds available in an 
existing account monitored by the central processing sys- 
tem. The central processing system then transmits authori- 
zation for or denial of the transaction to the remote terminal. 
In response to the message from the central processing 
system, the remote terminal dispenses cash (for an ATM) or 
the merchant provides the goods being purchased to the user 
if the authorization message indicates that the consumer's 
funds will be transferred to the merchant's account. Similar 
communication exchanges occur in data systems where 
electronic documents and other information are provided to 
a central site for compilation or processing. Consequently, 
this background discussion applies to all such transaction 
and data systems. Though the remainder of the discussion is 
directed to transaction systems, the reader should appreciate 
that the comments also apply to data systems as well. 

The remote terminals may be coupled to the central 
processing system in several ways. For example, in some 
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ATM systems, the ATMs are coupled to the central process- 
ing system through dedicated telephone or other data com- 
munication lines. These systems are preferred because they 
provide a relatively high degree of security since the dedi- 

5 cated data line coupling the central processing system to the 
ATM is not generally accessible by members of the public. 
The physical security of the dedicated data line is, however, 
expensive because no other traffic may utilize the line. Thus, 
the cost of leasing the dedicated line to an ATM with 

10 relatively low volumes of transactions may yield a high 
communication cost per transaction. 

In an effort to reduce the communication cost per 
transaction, some transaction or data systems utilize tele- 
phone lines through a publicly-switched telephone network 

15 (PSTN) which may be accessed by other members of the 
public. Specifically, devices such as credit card terminals 
and screen phone terminals typically include a modem 
which converts the digital messages of the remote terminal 
into frequency modulated analog signals which may be 

20 transmitted over telephone lines to a modem at the central 
processing system. In other systems, the terminal may 
communicate digital data directly over ISDN lines of the 
PSTN to the central processing system. This line of com- 
munication between a remote terminal and the central pro- 

25 cessing system is performed by having the remote terminal 
dial a telephone number associated with the central process- 
ing system to establish communication with the central 
processing system. This type of communication path is 
relatively secure because the switching networks for the 

30 communication traffic through the PSTN are not readily 
accessible by the public and during the course of the 
financial transaction, only the central processing system and 
remote terminal are on the line. 
Regardless of the communication method used to couple 

35 the central processing system to the remote terminals, the 
protocol and data formats used between the devices is 
typically proprietary. That is, the operator of each financial 
transaction system designs its own protocol and data mes- 
sage format for communication with the processor at the 

40 central site or generates a variant within a standard such as 
those established by the ANSI committee or the like for such 
communication. As a result, the remote terminals must 
include software that supports each operator's protocol and 
message formats in order to be compatible with an opera - 

45 tor's central site. For example, application software in a 
credit terminal such as the TRANZ330, TRANZ380, or 
OMNI 390 manufactured by VeriFone implement one or 
more of the communication protocols and formats for 
National Data Corporation (NDC), VISANET, 

50 MASTERCARD, BUYPASS, and National Bancard Corpo- 
ration (NaBANCO) system processors in order to support 
transactions with the most popular transaction centers. Thus, 
the communication software absorbs a significant amount of 
terminal resources which could be used to support other 

55 terminal operations. 

A related problem arises from the expanding home bank- 
ing market. A customer of home banking system typically 
uses a screen phone terminal or a personal computer (PC) 
having a modem to establish communication through a 

60 PSTN to a central transaction processing system. Again, the 
operator of the central processing system must provide 
information regarding the data message formats for com- 
municating with the central processing system to a vendor of 
software for the home banking terminals or must provide 

65 that software to its customers. As a result, home banking 
customers must purchase software to communicate with 
each banking system of which the customer wants to be a 
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member. This cost and the need to install additional com- information is directed to a standard monitor screen, user 

munication programs may make some consumers reluctant input is expected from a standard keyboard, and files are 

to be a member of more than one banking system or to transferred to standard peripherals such as a hard disk or 

change banking systems. diskette drive. Especially absent is the ability in open 

A communication system becoming increasingly popular 5 network protocols for communication with devices that only 

and which provides standardized communication is the use communication interfaces such as RS-232C. As a result, 

Internet. The Internet is an open network of networks which communication over the Internet is primarily performed 

communicate through a variety of physical communication with standard PCs through network communication methods 

devices such as telephone lines, direct communication lines, and interfaces. 

and the like. Each network is coupled to the main Internet 10 This presents a number of problems for home banking or 
network for communication through a host computer sup- for interfacing non-standard I/O terminals such as credit 
porting a TCP/IP router or bridger. The host computer card terminals or screen phones to open networks such as the 
typically includes a program, frequently called a Web server, Internet either directly or through a PC. Generally, non- 
which acts as a gateway to resources at the host computer standard I/O devices are devices which interface to a PC 
which may be resident on the host computer or a network 15 through a port not normally used for networks, such as a 
coupled to the host computer. Each server has an address RS-232C port, or are devices which have limited input and 
identifying the location of the resources available through output capabilities such as small screen displays or ten 
the Web server. The router recognizes communication for keypads. These devices are not supported on the Internet 
the server and directs the message to the server or it because servers use protocols that communicate with PCs 
recognizes that the communication should be forwarded to 20 supporting standard QWERTY keyboards and standard 
another server. As a. result, communication within the Inter- monitors. Consequently, users are limited to entering 
net may be point-to-point, but more likely, the communica- account numbers and the like through a keyboard of a 
tion path is a somewhat circuitous one with the information PC-like device for processing at a central transaction pro- 
passing through the "routers of multiple servers before reach- cessing system. To request a transaction, one need only have 
ing its final destination. 25 a person's credit card account number. If the credit card 
A number of message protocols and formats have been number had to be input through a magnetic card reader, 
developed for the Internet. The physical communication unauthorized access to a customer's account would be less 
protocol and data message format is the Transport Control likely since physical possession of the credit card would be 
Protocol/Internet Protocol (TCP/IP). The TCP/IP protocol required to initiate the transaction. 

involves multiple layers of encapsulating headers containing 30 Another limitation of the standard I/O devices currently 

communication information which are used to provide byte supported by the open network protocols is the lack of 

streams or datagram communications to computers on the encryption. For example, PIN pads, which are typically 

networks coupled to the Internet. Encapsulated within TCP/ incorporated in ATMs, automatically encrypt in hardware a 

IP headers are protocols which are used to format the data PIN entered by a user. Such devices typically encrypt the 

messages or transfer data from one computer to another 35 number by implementing a data encryption standard (DES) 

computer coupled to the Internet. These protocols include algorithm in hardware before the PIN is transmitted or 

File Transfer Protocol (FTP), Simple Mail Transfer Protocol stored. When a standard keyboard is used to input the PIN, 

(SMTP), Post Office Protocol (POP), Telnet, and Hyper Text no hardware encryption is performed and, as a result, an 

Transport Protocol (HTTP). The advantage of these proto- unencrypted copy of the PIN is provided to the memory of 

cols is that each provides a standardized communication 40 mc PC- Storage of unencrypted PINs is in contravention of 

format for transferring information between computers on current banking regulations. If PIN pads could be read via 

the Internet. These protocols are typically called open sys- Internet protocols, then such a lapse in PIN security would 

tem protocols ask they are publicly known and may be be less likely to occur. 

utilized by any programmer to develop programs for com- Another I/O device not supported on open networks are 

municating with another computer coupled to the Internet. 45 smart cards which are increasing in use. Smart cards include 

These non-proprietary protocols have contributed to the a processor and memory in which information regarding the 

acceptance of using the Internet as an open network for amount of funds in a particular account, a transaction 

coupling computer networks together. history, account numbers, and customer data may be stored. 

While the Internet provides an open network for computer The card may be read through a smart card reader which is 

communication with publicly accessible protocols and 50 a computer having a processor and memory but usually 

formats, the Internet suffers from a number of limitations provided with non-QWERTY keypads and limited displays, 

which preclude its effective use as a transaction or data A transaction processor may validate a card owner through 

system which uses non-standard I/O terminals and devices. a PIN provided through a keypad, determine the amount of 

First, circuitous communication presents a number of secu- money remaining on the card and debit the card itself for a 

rity issues for such a system. For example, a Web server 55 transaction amount by communicating with the smart card 

could incorporate a router which examines the address of reader with one of the proprietary protocols discussed 

each message coming through it and upon recognizing an above. Such information is not readily obtainable by the 

address associated with a central transaction processing owner of the card and so cannot be entered through a 

system, copy the data message for the unauthorized retrieval keyboard or the like. Smart card readers are non-standard 

of customer-sensitive information such as account numbers 60 devices which may be coupled to a PC through a COMM1 

and personal identification numbers (PINs) which may be or COMM2 port. However, none of the standard protocols 

contained in the message. and message formats for open network communications 

A second limitation of open networks such as the Internet currently provide I/O operations for such devices, 

is that communication on such networks is only supported All systems which attempt to provide three party com- 

for computers acting as servers or clients. Specifically, all of 65 munication to execute an electronic transaction suffer from 

the protocols and formats are constructed for standard a number of limitations which present risks greater than 

input/output (I/O) operations for a PC terminal. That is, text those in a normal transaction performed at the point of sale. 
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In a typical point of sale (POS) transaction, the consumer 
hands a debit or credit card to a merchant's agent who may 
examine the card for security markings such as holograms, 
watermarks, or a cardholder signature, The agent then places 
the card into a reader for acquiring information from the card 
and, in some cases, have the consumer enter a PIN into a PIN 
entry device which encrypts the PIN in a hardware imple- 
mented scheme. If the PIN is entered, it is transmitted with 
the information from the card to a processing center, typi- 
cally in one of the formats discussed above, under a X.25 
protocol or the like. The processing center returns an autho- 
rization granted or denied message. The reader typically has 
a printer coupled to it through an RS-232C port or the like 
and a purchase agreement is printed. The consumer signs the 
agreement, the merchant's agent may verify the signature, 
and the merchant retains an original of the agreement and the 
consumer a copy. In this scenario, the merchant has initiated 
the communication to the processing center. The safeguards 
noted above permit the processing center to charge a mer- 
chant a lower processing fee than when a consumer initiates 
a transaction. Consumer initiated transactions present a 
greater risk because the consumer provides an agent an 
account number in a telephone conversation or non- 
encrypted DTMF transmission. Thus, there is no card 
inspection, signature verification, or PIN verification. As a 
result, such transactions are limited to credit cards because 
debit cards require that the cardholder be present to enter a 
PIN into an appropriate PIN entry device. 

What is needed is a system that permits consumers remote 
from a merchant to order goods and present payment in a 
secured manner so the merchant's risk and processing costs, 
as well as a cardholder's exposure to fraud, is reduced. What 
is needed is a way for a processing center to communicate 
through an open network with non-standard I/O devices 
such as credit card terminals, personal digital assistants, and 
screen phone terminals or with non-standard I/O devices 
coupled to the open network through a PC or the like. What 
is needed is a transaction or data system which utilizes an 
open network such as the Internet to support electronic 
transactions or data compilation in a secure manner without 
undue limitation as to the devices with which communica- 
tion may be made. 

SUMMARY OF THE INVENTION 
The present invention provides transaction and data sys- 
tems which may be implemented on an open network such 
as the Internet. The system comprises a server for commu- 
nicating in an open network protocol and a plurality of 
input/output (I/O) devices coupled to the server through an 
open network, the I/O devices communicating with the 
server in the extended open network protocol that supports 
communication with non-standard I/O devices over the open 
network. The system of the present invention provides a 
server with the capability of communicating with a number 
of I/O devices useful in transaction and data systems which 
heretofore have been unsupported on an open network 
system such as the Internet. 

The system of the present invention is implemented by 
extending present open network communication protocols 
and data message formats to communicate with non- 
standard I/O devices either coupled to an open network as a 
client or coupled to an open network through a client, such 
as a PC, credit card terminal, screen phone, or PDA, That is, 
commands which are compatible with the communication 
schema of a presently- implemented protocol for the Internet 
are used and additions are made to commands implemented 
within the control structure of that existing protocol to 
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support non-standard I/O device communication. At the 
server, the extended protocol is further supported by a 
common gateway interface (CGI) which converts the com- 
munication from a non-standard I/O device to a format 

5 which is compatible with a transaction or data application 
program which may be executed on the server or a computer 
coupled to the server. In this manner, the CGI permits the 
processing of the extended capability commands to be 
segregated from the communication functions performed by 

10 the server. 

Preferably, the server and the I/O devices communicate 
through an Internet protocol and most preferably, the Hyper 
Text Transport Protocol (HTTP), to exchange data between 
an application program and non-standard I/O devices over 

!5 an open network. Although HTTP is the preferred protocol 
used to implement the present invention, other protocols 
such as Telnet or SMTP, for example, may also be extended 
in a similar manner. Specifically, the HTTP protocol is 
expanded to communicate with printers, magnetic card 

20 readers, credit card terminals, smart card readers, check 
readers, PIN pads, bar-code readers, PDAs, or the like, and 
includes a command which instructs a non-standard I/O 
device to disconnect from the open network and re -couple to 
a transaction processing system to transfer funds from a 

25 consumer account to a merchant account through a PSTN or 
dedicated data line. By using these extended capability 
commands within HTTP, a processing system may operate 
on an open network such as the Internet and communicate 
with transaction or other data I/O devices which have not 

30 previously been able to couple to such open networks. Such 
a system may be used to execute a transaction between a 
consumer and a merchant so the merchant receives remit- 
tance information in a timely manner. The system permits 
the consumer to initiate a transaction and order from a 

35 merchant and then use a more secure link supported by PIN 
entry devices or the like to reduce the risk of fraud for the 
transaction. 

Because the server may communicate through such open 
networks with non-standard I/O devices, the transaction or 

40 data processing system is available for the ever-expanding 
market available through the Internet. Such a system is able 
to communicate with non-standard I/O devices in myriad 
locations such as retail establishments or in consumers* 
homes. For example, a consumer may utilize the standard 

45 capability of an Internet protocol to communicate with a 
server that provides information regarding services or goods 
for sale over the Internet and then consummate a sales 
transaction by using the extended capability of the Internet 
protocol. Such a home consumer could provide transaction 

50 data through a smart card reader coupled to a COMM1 or 
COMM2 port of a PC. A database program executing at the 
server for the central processing site may accept product 
ordering information from a non-standard keypad or touch 
screen associated with a screen phone terminal at the remote 

55 site and then communicate with the smart card reader to 
consummate the transaction. Such a transaction system 
requires that the consumer have physical possession of the 
smart or credit card and not simply knowledge of the 
account number. Likewise, the server would be able to 

60 communicate with a PIN pad or the like to ensure the 
hardware encryption of PINs and other data before it is 
transmitted to the server site. Such a system is less suscep- 
tible to consumer fraud. 
Another feature of the present invention is a PAYMENT 

65 command implemented in the extended Internet protocol 
that directs a non-standard I/O device or a PC interfaced 
with such devices to communicate with a transaction pro- 
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cessor through an alternative communication link. In one In the most preferred embodiment, the editor permits a user 
form, the PAYMENT command is used by a merchant to develop integrated forms comprised of the extended 
terminal to submit a consumer's account number with a HTML language and standard query language (SQL) data- 
merchant deposit account number through a PSTN network base application statements. In this manner, the user does not 
or the like to the processing center. In another form of the 5 have to manually generate the SQL commands, the HTML 
PAYMENT command, a client program in a consumer's commands, and carefully correlate the data fields of the two 
terminal receives an account number for a merchant account commands in order to implement a transaction between a 
from a merchant's server with the PAYMENT command. On client and a database. 

receipt of this command, the client program suspends its and other advantages and features of the present 

operation and passes the account number to a conventional 10 invention may be discerned from reviewing the accompa- 

bank processing program co-resident in memory. The bank nying drawings and the detailed description of the invention, 
processing program establishes a standard communication 

link with a transaction processing system through a dedi- BRIEF DESCRIPTION OF THE DRAWINGS 

cated data line or a PSTN network. Using that communica- Th e present invention may take form in various compo- 

tion link, the bank processing program executes a commer- 15 nents and arrangement of components and in various steps 

cial transaction using a standard VISA protocol or the like. anc j arrangement of steps. The drawings are only for pur- 

The consumer may use a magnetic stripe reader and a PIN po^s 0 f illustrating a preferred embodiment and are not to 

entry device to improve the security of the data transmission. b e construed as limiting the invention. 

The transaction center may transmit remittance data over the FIG. 1 is a diagram of an open network system in which 

open network to the merchant so the merchant is apprised of 20 me present invention is utilized; 

payment and ships the ordered product. Once this consumer ^ . f it _ c A c 4 . ™« nkJf * 

• . j . *■ • 1 ; *u l 1 • FIG. 2 is a diagram of the format of the FORM and 

initiated transaction is complete, the bank processing pro- Ixmi ™ A . °^ . , . c , . , r 

, ^ r \ 1 * *i_ !• * INPUT tags implemented in the preferred embodiment of 

gram terminates and returns control to the client program ^ resent invention* 

which may terminate communication with the open network ^ 5 

or retrieve information from another server on the open 2 S FIG. 3 is a diagram of the preferred SQL commands 

network for another transaction. In this way, the user may supported in the preferred embodiment of the present inven- 

use the open network for non-confidential communication k° n » 

such as collecting product information, pricing, and product FIG * 4 is a flowchart of the high level processing of the 

availability. This information may be collected quickly and client program which interprets the HTML files of the 

efficiently using the extended Internet protocol. The con- 30 preferred embodiment of the present invention; 

ventional bank processing program and more secure com- FIG. 5 is a flowchart of the HTML file processing 

munication links may then be used for the confidential performed by the client program of the preferred embodi- 

information required for the transaction. Thus, the present ment of the present invention; 

invention is able to combine the features and advantages of FIG. 6 is a flowchart of the attribute processing for the 

the Internet with the more secure communication link and 3s FORM tag performed by the client program of the preferred 

data security enhancing devices of systems presently known. embodiment of the present invention; 

Preferably, an editor is provided which permits a user to FIG. 7 is a flowchart of the processing of the ACTION 

define an application database table with data fields, define attribute for the FORM tag performed by the client program 

client application data fields, and define the integrated forms of the preferred embodiment of the present invention; 

for communicating data between the defined database tables 40 piG. 8 is a flowchart of the processing for the METHOD 

and a client application. The editor verifies the syntax of the attribute for the FORM tag performed by the client program 

user generated integrated forms containing extended Inter- D f me preferred embodiment of the present invention; 

net protocol statements and client application statements. FIG 9 is a fl 0WCDa rt of the attribute processing for the 

The editor ensures that the variable names for the client INPUT tag performed by the client program of the preferred 

application and the data fields for the database application 45 embodiment of the present invention; 

correspond. Following the generation of the integrated form, nG 10 ^ a flowchart of the processmg for the TYPE 

the editor parses the integrated form to segregate the data- fof {hQ {wm rformed 5 the client m 

base language statements from the extended Internet proto- of {h& fcrred embodime[lt of tne present irjven tio n; 

col statements. A database language identifier is substituted ^ . a , ^ £ . . c lL Kliwr 

. y . . . . . . 7 c ^ j * l * * FIG. 11 is a flowchart or the processing tor the NAMb 

in the Internet protocol statements for the database state- 50 „ ., , ri , ..mT™, <. , , ? , 

, . J. . t 4 . - ™ T t 4 t attribute of the INPUT tag performed by the client program 

me nts contained in the integrated form. The Internet proto- r r , , br t f4l _ J . J 

li4 4 . ,j. £i i* !• • » * j of the preferred embodiment of the present invention; 

col statements are downloaded as a file which is interpreted m „ . ^ , „ 

by the client program for the collection and submission of FI U G - " ,s u a d ' a £\ m of the j omi " f ° r "? e ACTI0N 

data from non-standard I/O devices to the database appli- aUnbute for J he ?° RM ta f PJjfonn«> by the common 

cation. Hie database language statements segregated from 55 8«eway interface between the Web server and an applica- 

the extended Internet protocol statements are placed in a Uon P r °g ram > 

second file which is named to correspond to the database FIG - 13A is a diagram of the possible communication 

table defined by the user. The CGI application recognizes the paths which may be used by an I/O device according to the 

database language identifier contained in the returned forms principles of the present invention; 

of the Internet protocol statements. The CGI application 60 FIG. 13B shows an exemplary FORM tag and INPUT tag 

correlates the database identifier with the file previously for tne PAYMENT method implemented in a merchant's 

generated by the editor which contains the database com- terminal according to the principles of the present invention; 

mand statements. The application then inserts the data from FIG. 13C shows an exemplary FORM tag and INPUT tag 

the returned form into the database command statements and for the PAYMENT method implemented in a consumer's 

provides the re-integrated database command statements to 65 terminal according to the principles of the present invention; 

the database application. In this manner, the database maybe FIG. 14 shows exemplary integrated statements for a file 

queried by or retrieve data from the non-standard I/O device. used in the preferred embodiment of the present invention to 
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generate the HTML files for the client program and the SQL 
files for the application program for a card initiated payment 
authorization and capture transaction; 

FIG. 15 shows exemplary integrated statements for a file 
used in the preferred embodiment of the present invention to 5 
generate the HTML files for the client program and the SQL 
files for the application program for a bar code reader input 
with card-initiated payment authorization transaction; 

FIG. 16 shows exemplary integrated statements for a file 
used in the preferred embodiment of the present invention to 10 
generate the HTML files for the client program and the SQL 
files for the application program for a key input order with 
secure payment transaction; 

FIG. 17A shows exemplary integrated statements for a file 
used in the preferred embodiment of the present invention to 
generate the HTML files for the client program and the SQL 
files for the application program for a smart card debit (Type 

1) transaction; 

FIG. 17B shows exemplary integrated statements for a file 20 
used in the preferred embodiment of the present invention to 
generate the HTML files for the client program and the SQL 
files for the application program for a smart card debit (Type 

2) transaction; 

FIG. 18 shows exemplary integrated statements for a file 25 
used in the preferred embodiment of the present invention to 
generate the HTML files for the client program and the SQL 
files for the application program for a debit card transaction; 

FIG. 19 shows exemplary integrated statements for a file 
used in the preferred embodiment of the present invention to 30 
generate the HTML files for the client program and the SQL 
files for the application program for a check verification 
transaction; 

FIG. 20 shows exemplary integrated statements for a file 
used in the preferred embodiment of the present invention to 35 
generate the HTML files for the client program and the SQL 
files for the application program for a customer frequency 
transaction; 

FIG. 21 shows exemplary integrated statements for a file 
used in the preferred embodiment of the present invention to 40 
generate the HTML files for the client program and the SQL 
files for the application program for an item search trans- 
action; 

FIG. 22 shows exemplary integrated statements for a file 
used in the preferred embodiment of the present invention to 
generate the HTML files for the client program and the SQL 
files for the application program for retail store end of day 
reporting; 

FIG. 23 shows exemplary integrated statements for a file SQ 
used in the preferred embodiment of the present invention to 
generate the HTML files for the client program and the SQL 
files for the application program for a store reporting an 
e-mail transaction; 

FIG. 24A is a diagram of a manual development process 55 
for the files interpreted by the client program and the files 
interpreted by the application program in accordance with 
the principles of the present invention; and 

FIG. 24B is a diagram of the generation of the files 
interpreted by the client program and the files interpreted by 60 
application program performed by an editor constructed in 
accordance with the principles of the present invention. 

DETAILED DESCRIPTION OF THE 
INVENTION 

to 

A transaction or data system constructed in accordance 
with the principles of the present invention is shown is FIG. 
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1. The system 10 includes a Web server 12 which is coupled 
to an open network 14 such as the Internet for communica- 
tion with various I/O devices and terminals. For example, 
the I/O devices which may be coupled directly to network 14 
include standard I/O devices already supported by Internet 
protocols such as PCs 30 and non-standard I/O devices such 
as a screen phone terminal 16, a personal digital assistant 
(PDA) 18, and a credit card terminal 20. Other exemplary 
non-standard I/O devices such as smart card reader 32, 
personal identification number (PIN) pad 34, magnetic card 
swipe reader 36, printer 38, or the like, may be coupled to 
PCs through non-standard I/O ports such as COMM1 and 
COMM2 ports or to other non-standard I/O devices such as 
phone terminal 16, PDA 18, or credit card terminal 20. 
Typically, these devices are coupled to PCs or devices 16,18, 
or 20 through an interface such as a RS-232C interface. 
Merchants or other vendors may use a Web server 2 to 
couple to network 14 to communicate with the devices and 
processing system 40. 

The Web server 12 is preferably coupled to a Common 
Gateway Interface (CGI) application 28 which converts and 
communicates the data and commands between the devices 
on network 14 and the processing system 40 so the I/O 
devices do not have to use the database command language 
to interact with the database. System 40 and the devices may 
communicate directly if they are implemented in the same 
language or if a user implements a communication interface 
such as CGI 28 that correlates data fields in the client with 
those in system 40. Server 12, CGI 28, and the applications 
supporting system 40 may all reside on a single host 
computer or they may reside on separate computers coupled 
together by a local area network (LAN) or a wide area 
network (WAN). Preferably, the application interfaces with 
a database which supports Open Data Base Connectivity 
(ODBC) and Structured Query Language (SQL), 

The communication sessions between the I/O devices 
coupled to the open network 14 and the Web server 12 are 
generally conducted in the same fashion as Internet protocol 
communication sessions are currently performed. That is, 
the I/O device establishes a communication connection with 
Web server 12, sends a request to the Web server, the Web 
server responds to the request and the I/O device or server 
closes the connection. Preferably, the non-standard I/O 
devices or PCs interfaced to such devices selectively couple 
to a local access port on the open network 14 through a local 
modem/ISDN connection. In this manner, the device is only 
coupled to the open network 14 when a transaction or a data 
operation is to be performed. While connected to the open 
network 14, a device may access a number of servers to 
accomplish a purpose. For example, a device may couple to 
a local access port and communicate with a first server to 
check inventory levels at a site, communicate with a second 
server to order stock for the inventory, and communicate 
with a third server to settle payment for the ordered goods. 
When all aspects of the transaction are complete, the con- 
nection with the local access port is terminated. In the 
preferred embodiment of the present invention, the protocol 
used to transport data messages between Web server 12 and 
the I/O devices coupled to the open network 14 is the Hyper 
Text Transport Protocol (HTTP), although other open sys- 
tem protocols utilized on the Internet may be used. 

In standard HTTP protocol, a client program executing in 
one of the I/O devices may initiate communication with a 
server by sending a query message of the format: 

http://<host>: <port>/<path>?<search part> 

The message identifies the client as seeking communica- 
tion with a HTTP server at the host address on the specified 
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port. In the HTTP protocol, the default value for the port is 
80 and the host address is the Internet protocol (IP) address 
of the type well-known in the art. The path value selects the 
file in the HTTP server which is activated in response to the 
message and the search part specifies a query for the selected 5 
file. In the initial communication, the query may be omitted 
so that the selected host file responds to the client program 
before a query is processed. 

In the present invention, the client program uses a similar 
message to initiate a transaction or data operation, except 
that database commands are preferably embedded in a file at 
the server 12 and not in the "search part" of the command, 
although search parts may be constructed in accordance with 
the principles of the present invention that support non- 
standard I/O devices. Preferably, the client program inter- 
prets Hyper Text Markup Language (HTML) files contain- 15 
ing HTML commands for communicating data between 
non-standard I/O devices and server 12. Most preferably, the 
HTML commands contain identifiers which are used by the 
CGI to place data returned in the forms of the HTML 
commands into database commands for queries or data 20 
insertions for the database. HTML is a command language 
well known for the retrieval and display of electronic 
documents for standard I/O devices such as PCs supported 
by full screen monitors, QWERTY keyboards, and standard 
peripherals such as hard disk drives and diskette drives. 2 5 
Standard HTML commands use text and previously known 
commands that reference Universal Resource Locators 
(URLs) to support the communication of electronic docu- 
ments. These documents are files which may contain HTML 
commands, text, audio, video, or image data. The present 30 
invention extends HTML with commands that support com- 
munication between the server and the non-standard I/O 
devices. 

In the HTTP protocol, data may be obtained during a 
communication session by using a tag called a FORM as part 35 
of the file defined by <path> in the command discussed 
above. The FORM format for standard HTTP is: 



<FORM ACTION-"URL" 
METHOD-GET POST 

> 

Command 
</FOKM> 



where "|" is an "OR" operator. The commands supported 
by standard HTTP are INPUT, SELECT, and TEXTAREA. 
Additionally, standard HTTP permits the inclusion of text 
data in the command area. In the present invention, HTML 
has been extended to support new ACTIONS, METHODS, 50 
and INPUTs. 

In accordance with the principles of the present invention, 
tags are preferably used to identify device transfers and 
input operations. Preferably, the FORM tag is used to 
identify device transfers and ACTION and METHOD 55 
attributes further identify the device operation. As shown in 
FIG. 2, the extended ACTION field may include a FROM 
and TO attribute for accessing a local terminal file or smart 
card reader or a TO PRINTER attribute for directing output 
data to a printer local to the I/O device. The FROM and TO 60 
attributes for accessing local files and smart card readers and 
for directing output data to a local printer have previously 
been unsupported in any Internet protocol. As a result, the 
server 12 may access non-standard I/O peripherals for any of 
the I/O devices used in the transaction or data system 10. 65 
The ACTION-" URL" is a part of standard HTTP and is well 
known. 
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The METHOD attributes may include the GET, POST, 
PAYMENT, or SQL methods. The GET and POST methods 
are currently supported in standard HTTP and are well 
known. The PAYMENT attribute is a directive to deliver 
data retrieved by an INPUT command to a private payment 
network for authorization and settlement and is not available 
in current Internet protocols. This directive is used by the 
client program to activate a conventional financial transac- 
tion application which communicates with the transaction 
system over a dedicated data line or PSTN in a known 
protocol such as VISA. Such an attribute is used where the 
more secure physical connection between remote site and 
transaction system and data encryption devices or the like 
are preferred. The SQL method preferably identifies a data- 
base language file which CGI 28 uses to correlate data in the 
HTML FORM to an insertion or query command contained 
in the file. 

The preferred format for the INPUT tag which is used to 
identify input operations is also shown in FIG. 2. The TYPE 
and NAME attributes are used to define a non-standard I/O 
device or local storage variable for the input of data. The 
TYPE field values "text," "password," "checkbox," "radio," 
"submit," and "reset" are previously known, as are the 
attributes NAME, VALUE, CHECKED, SIZE, and MAX- 
LENGTH. To support the extended capability of the present 
invention, the TYPE attribute preferably includes attributes 
MSRT1 for reading track 1 of a magnetic swipe reader, 
MSRT2 for reading a magnetic swipe reader track 2, KEY 
for reading input from a terminal command keypad, PIN for 
reading a personal identification number pad, BCW for 
reading a bar code wand, MICR for reading a check mag- 
netic code reader, ATM for reading a dollar amount via a key 
input mask, INT for reading an integer via a key input mask, 
LOCAL for reading input from a variable in the local storage 
of an I/O device, and AUTOSUBMIT for returning a FORM 
with information to the server. 

The NAME attribute used with the INPUT tag identifies 
reserved word names for local storage in the device execut- 
ing the client program. Preferably, the NAME attribute 
identifies ip_address, host_phone, tid, work_key, 
datetime, and deposit_acct as local storage areas in the local 
device for the terminars Internet Protocol (IP) address, 
Internet access phone number, terminal ID, PIN encryption 
working key, date/time, and merchant account number, 
respectively. These attributes are used with the INPUT tag to 
read non-standard I/O devices which may be coupled to 
open network 14. For example, an INPUT TYPE=MSRT1 
attribute causes the client program residing within a mag- 
netic stripe reader to input data from track 1 of a stripe reader 
and insert that data into a FORM which is returned to Web 
server 12 for processing by an INPUT TYPE- 
AUTOSUBMIT statement. 

Preferably, the database language commands which may 
be embedded in the extended HTML are SQL commands 
such as those shown in FIG. 3, although other database 
languages may be used. The SELECT command may 
include the names of data fields in a database so the device 
on network 14 may request a data item from a database at the 
central processing system. The database table is identified by 
the FROM attribute and the conditional selection of data 
from an identified database table may be defined by a 
WHERE attribute. Additionally, records may be requested 
from an identified database in ascending or descending order 
or in groups of two records at a time using the ORDER 
attribute. Additionally, the SELECT field command with the 
GROUP attribute provides I/O devices with the capability of 
retrieving records grouped under an identified name. 
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Additionally, the I/O devices may either insert new data into 
an identified database with the INSERT attribute or update 
data already existing in a database with the UPDATE 
attribute. The values for the INSERT attribute may be 
identified with the VALUES attribute, and the SET and 
WHERE attributes may be used to define and conditionally 
update values in the identified database. Preferably, the 
present invention implements two DELETE and CREATE 
attributes. The DELETE attribute deletes all items in an 
identified column of a database table which may satisfy a 
condition defined by a WHERE attribute. The CREATE 
attribute creates a database table having a primary key 
identified by the PRIMARY KEY attribute. 

Preferably, the server program executes on a computer 
system having at least an Intel 80386 or better processor 
with at least 4 megabytes of RAM and at least 3 megabytes 
of hard disk space available. The computer system running 
the server may operate any known server platform operating 
system such as WINDOWS 3.1, WINDOWS 95, or WIN- 
DOWS NT, UNIX, AIX, and others. The non-standard I/O 
devices require a processor of a Z80A type or better, at least 
32K bytes of RAM, and at least 32K bytes of ROM. The 
device includes a modem capable of at least 1200 bits-per- 
second (bps) but other modem speeds may be used for 
communication between client and server. Alternatively, the 
device may be coupled to a LAN which in turn is coupled 
to the Internet for communication with server 12. Atypical 
non-standard device which executes the client program is a 
VeriFone OMNI390, OMNI395, or VuFone terminal. 
OMNI390, OMNI395, and VuFone are trademarks of 
VeriFone, Inc., of Redwood City, Calif. Other exemplary 
devices include Phillips Screen phone, Hypercomm T7 
terminal, and Apple Computer Newton MessagePad. 

To build the preferred HTML files which CGI 28 prefer- 
ably uses to implement the client program and database 
application, the user preferably uses an off-line editor. The 
files generated by the editor are preferably comprised of an 
integrated statements formed from HTML statements and 
database statements for retrieving and writing data with the 
database. Exemplary files showing such integrated state- 
ments for performing transactions are depicted in FIGS. 
14-23B. After such a file is generated, the editor parses the 
integrated statements into HTML statements and into data- 
base statements such as SQL commands. The HTML files 
required by the client program to support communication 
with a transaction or data processing center may be down- 
loaded to a device or PC for execution. The files containing 
the database application statements used by the CGI inter- 
face to communicate data with the database application 
program preferably reside on server 12. Preferably, the 
database files used by the CGI interface include SQL com- 
mands for the application program interfaced to an ODBC 
compliant database. 

The general format of the HTML commands in the HTML 
files used for communication with a client program and 
server are of the general format: TAG ATTRIBUTE. 
Preferably, the TAG field may be one of FORM, INPUT, 
SQL, or TEXTAREA. The ATTRIBUTE field value depends 
upon the TAG value. Preferably, the FORM tag may include 
the ACTION or METHOD attributes where the ACTION 
attributes include the FROM<file>, TO PRINTER, 
TO<file>, and TO SCR values noted above, as well as the 
standard HTML ACTION value of URL-<file>. The 
METHOD attributes include the PAYMENT and SQL 
attributes noted above, as well as the standard HTML 
METHOD values of GET and POST. Also in accordance 
with the principles of the present invention, the INPUT tag 
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may include TYPE, NAME, VALUE, CHECKED, SIZE, 
and MAXLENGTH attributes. These attributes are previ- 
ously supported for the INPUT tag in HTML, however, the 
present invention further includes TYPE values of MSRT1, 

5 MSRT2, KEY, PIN, BCW, MICR, AMT, INT, LOCAL, and 
AUTOSUB, as well as the standard HTML TYPE values of 
TEXT, PASSWORD, CHECKBOX, RADIO BUTTON, 
SUBMIT, and RESET The present invention also supports 
NAME attributes of IP_ADDRESS, HOST_PHONE, TID, 

10 WORK_KEY, DATETIME, and DEPOSIT_ACCT to 
identify local storage areas as well as standard HTML 
NAME attribute <Field_NM> to identify a FORM variable. 

The preferred high level processing of the client program 
is shown in FIG. 4. That processing includes an idle step 

35 (Block 100) in which the program performs general house- 
keeping tasks such as maintaining internal time, scanning 
for input which may activate the device, or other known 
functions. Further processing is activated by some operator 
action at the device or PC which causes the device to either 

20 open a remote URL (Block 102) or open a local URL (Block 
104). If a remote URL is required, the device transmits a 
message of the format discussed previously which is routed 
through the open network and delivered to a server 12 for a 
transaction or data processing system (Block 106). The 

25 HTML file selected at the server 12 is identified by the 
remote URL in the initial communication between the 
device and server 12 and that URL is used to return the 
selected HTML file to the device for processing (Blocks 108, 
110). 

30 FIG. 4 also shows that an operator may initiate an open 
local URL function by typing in a command or by pushing 
a hot key which is associated with a local URL. The I/O 
device reads the HTML file identified by the URL from local 
memory (Block 112) and passes the HTML file to the 

35 function for processing HTML files (Block 110). After a file 
is processed (Block 110), the client program determines 
whether the HTML file is to be stored (Block 114). If it is 
not, the process returns to the idle processing (Block 100). 
Otherwise, the process determines whether the HTML file is 

40 to be associated with a hot key (Block 116) and, if it is, it 
stores the file and generates the link between a hot key and 
the stored file (Blocks 118, 120). If the HTML file is only to 
be stored, no association is made with a hot key and the file 
is simply stored in local memory (Block 20). The client 

45 program then returns to idle processing (Block 100). 

The high-level processing for the HTML file (Block 110, 
FIG. 4) is shown in further detail in FIG. 5. The process 
begins by scanning the HTML file for a TAG (Block 140). 
If no TAG is found, the file is not in proper format for 

50 processing and processing returns to Block 114 discussed in 
FIG. 4 above. If a TAG is found (Block 142), the process 
determines whether the TAG is a FORM TAG (Block 144) 
or an INPUT TAG (Block 146). If it is a FORM TAG, then 
the FORM TAG is processed and the program continues by 

55 looking for other TAGS to process (Block 140). If the TAG 
is an INPUT TAG, the INPUT TAG is processed (Block 
150) and the program continues by looking for other TAGS 
to process (Block 140). If the TAG is one of the standard 
HTML TAGS, the program implements the TAG in standard 

60 known ways (Block 152) and then scans for other TAGs to 
process (Block 140). 

Processing the ATTRIBUTES used to implement a 
FORM TAG is shown in FIG. 6. That process continues by 
scanning the HTML file for an attribute (Block 160). If an 

65 attribute is not found (Block 162), the program returns to 
scan for other TAGS (Block 140, FIG. 5). If an attribute is 
found, the program determines whether it is an ACTION 
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attribute (Block 164) or a METHOD attribute (Block 166). 
Depending on the type of attribute, the appropriate function 
for processing the attribute is executed (Blocks 168 or 170) 
and scanning for additional attributes continues (Block 160). 
If the attribute is not an ACTION or METHOD attribute, 5 
there is an error in the file and processing returns to scan for 
other TAGs. 

The processing for the ACTION attribute is shown in FIG. 
7. There, the ACTION attribute is examined to determine 
whether it is a FROM<file> (Block 180), TO PRINTER 10 
(Block 182), TO<flle> (Block 184), TO SCR (Block 186), 
FROM SCR (Block 188) or a URL«<file> (Block 192). The 
URL=<file> ACTION is a standard HTML action which is 
processed in a known way (Block 194). The FROM <file> 
action is processed by reading data from a file associated 15 
with the I/O device or PC interfaced to the I/O device (Block 
196). The TO PRINTER action results in data in the FORM 
being sent to the printer (Block 198) while the TO 
<file> action results in data in the FORM being written to a 
local file (Block 200). The TO SCR action causes data to be 20 
written to the smart card via a smart card reader (Block 202) 
and the FROM SCR reads data from a smart card through a 
smart card reader (Block 204). After the appropriate action 
processing takes place, the HTML file is scanned for addi- 
tional ACTION values to perform (Block 206), and if one is 25 
found, the process continues. If no attribute is located (Block 
208), the process returns to scan for other attributes (Block 
160, FIG. 6). 

The processing for the METHOD attributes for FORM 
tags are shown in FIG. 8. The process determines which type 30 
of METHOD is present in the FORM and then properly 
processes the attribute. For the GET and POST methods 
(Blocks 210, 212) the processing is the same as that per- 
formed in standard HTML (Blocks 226, 228). That is, for the 
GET method, the identified URL<file> is queried for data 35 
while the POST attribute causes data to be transferred to the 
URL<file>. The preferred METHOD attributes extending 
the HTML implementation of the present invention are SQL 
(Block 214), and PAYMENT (Block 224) attributes. The 
SQL attribute is preferably not expanded into a SQL com- 40 
mand at the client, but rather is expanded by the CGI 28 at 
server 12 by correlating the data or variable field names in 
a returned form with the SQL commands stored at the server. 
This processing is done in a manner described in more detail 
below. The client program passes the SQL file identifier to 45 
the server 12 (Block 230). The processing of the PAYMENT 
command (Block 232) is discussed in more detail below. 
The HTML file is scanned for other METHODS (Block 242, 
244), and, if one is found, the processing continues by 
identifying the METHOD (Blocks 210-224). Otherwise so 
(Block 244), the process returns to scan the HTML file for 
other ACTION or METHOD attributes (Block 160, FIG. 6). 

Processing for the INPUT tag is shown in FIG. 9. The 
process scans the HTML file following the INPUT tag for 
attributes (Block 250). If no attributes are found (Block 55 
252), the process continues by scanning the HTML file for 
other tags to process (Block 140, FIG. 5). If an attribute is 
found and it is a TYPE attribute (Block 254), it is processed 
(Block 256), and if the attribute is a NAME attribute (Block 
258), it is processed (Block 260). Both the TYPE and 60 
NAME processing is shown in more detail in FIGS. 10 and 
11, respectively. If the attribute is neither a NAME or TYPE 
attribute, it is a standard attribute for an INPUT tag sup- 
ported by standard HTML and is processed in a known 
manner (Block 262). Following processing of the INPUT 65 
attribute, the HTML file is scanned for other attributes to 
process (Block 250). 
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Processing for the TYPE attribute is shown in FIG. 10. 
The process first identifies the TYPE attribute for the INPUT 
tag and then performs the appropriate processing. The new 
TYPE attributes of the preferred embodiment of the present 
invention are MSRT1 (Block 270), MSRT2 (Block 272), 
KEY (Block 274), PIN (Block 276), BCW (Block 278), 
MICR (Block 280), AMT (Block 282), INT (Block 284), 
LOCAL (Block 286), and AUTOSUB (Block 288). If the 
TYPE attribute is not one of these, it is a standard HTML 
type attribute that is processed in a known manner (Block 
310). Each of the new HTML TYPES supported by the 
present invention causes an I/O operation with a non- 
standard device. Specifically, these operations are the read- 
ing of Track 1 of the magnetic stripe reader (Block 290), the 
reading of the second track of the magnetic stripe reader 
(Block 292), the reading of a keypad (Block 294), the 
reading of an encrypted PIN through a PIN entry device 
(Block 296), the reading of a bar code through a bar code 
reader (Block 298), the reading of encoded data on a check 
through a magnetic check reader (Block 300), the reading of 
a dollar amount from a keypad through a key input mask 
(Block 302), the reading of a number from a keypad through 
a key input mask (Block 304), the reading of data from a 
local variable (Block 306) and the submission of the data 
read from one of these devices in a FORM returned to the 
server 12 (Block 308). The data mask for AMT constrains 
the dollar amount read to a predetermined number of char- 
acters with only two characters following the decimal point. 
The data mask for INT ensures the number is an integer 
value within a predetermined range. Processing continues by 
scanning the HTML file for other TYPE attributes (Block 
312) and, if another TYPE attribute is found (Block 314), 
processing continues by determining the TYPE attribute and 
performing the appropriate processing. Otherwise, the pro- 
cess returns to scan the HTML file for other attributes (Block 
250, FIG. 9). 

The NAME attribute processing is performed in accor- 
dance with the process shown in FIG, 11. That process 
examines the NAME attribute to determine if the variable 
name identified by the attribute is IP_ADDRESS, HOST_ 
PHONE, TID, WORie_KEY, DATETIME, or DEPOSIT_ 
ACCT (Blocks 320, 322, 324, 326, 328, 330). If they are, the 
INPUT value resulting from one of the INPUTS in a FORM 
of the HTML file is stored in a local variable identified by 
the NAME attribute. Following storage (Block 332), the file 
is scanned for other NAME attributes (Block 328) and, if 
there are none (Block 332), processing continues by scan- 
ning for other attributes for the INPUT tag (Block 250, FIG. 
9), If the NAME attribute is a standard HTML INPUT 
NAME, it is processed by known methods (Block 336). 
Processing then continues by scanning for other NAME 
attributes to process (Block 338, 340). Otherwise, the pro- 
cess returns to scan the HTML file for other attributes (Block 
250, FIG. 9). 

CGI 28 receives Internet protocol statements in a file 
transmitted from a client program and provides data from 
those statements to the applications) implementing system 
40 and receives the output of system 40 and provides them 
to the client program in a file. CGI 28 may be implemented 
by a program developed by a user using a manual develop- 
ment method as shown in FIG. 24A. That method requires 
a user to generate a system definition from which a file 
statement definition for the client and application are devel- 
oped to implement the transactional or data system. Using 
the file statement definitions, the user generates the files for 
the client and database programs which are interpreted by 
the respective programs to implement transactions or data 
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processing. This process requires the user to not only have FORM and submitted to a server file at a processing system 

knowledge regarding the transaction or data process but address. The server file activates CGI 28 which retrieves 

specific details of the interaction between the client and data from the FORM and incorporates it into database 

database. The user is further required to resolve and corre- statements in the database file for the appropriate transaction 

late all data identifiers in the statements for the client and 5 and database. If the database statement is a query, the 

database environments. requested data is returned to the CGI in the database file and 

Preferably, CGI 28 is developed with an editor that only the CGI places it in the corresponding FORM variables so 
requires the user to define the system with statements which the server may return the data to the terminal. If the database 
are an integration of the protocol statements and the data- statement provides data to a database to obtain an 
base language. The process implemented by this editor is to authorization, for example, the action performed by the 
shown in FIG. 24B. Examples of such integrated statements database application in response to the data is placed in the 
for files which implement a specific transaction are shown in corresponding FORM and returned to the terminal. In this 
FIGS. 14 to 23B. The editor verifies the syntax of the way, data is exchanged between the terminal and the data- 
integrated statements and correlates the data variables of the base application. This exchange is supported by CGI 28 
protocol statements with the data fields of the database. 15 even though the server/client communication is performed 
Following the generation of the integrated statements, the in an open system protocol, such as HTTP, and the database 
editor segregates the protocol statements from the database application is performed in another language, such as SQL. 
language statements. The protocol statements are stored in CGI 28 is able to convert and exchange the data between the 
files which are identified as being for a particular transaction client and database without the user having to specifically 
or data process and the database statements are stored in files 20 design and implement a conversion program, 
which are identified as being for a particular transaction or The communication paths available for a device imple- 
dala process on an identified database table. The editor menting the present invention are shown in FIG. 13A. As 
places a database file identifier in the protocol statements shown there, an I/O device 420 is coupled through the 
which contained embedded database statements. The data- Worldwide Web open network 426 to an Internet Web server 
base file identifiers are used by CGI 28 to select the file for 25 12. This connection may be implemented with the preferred 
the appropriate transaction so CGI 28 may correlate data extended capability HTML described above. Although 
variables in the protocol statements with data fields in the HTML files may be encrypted to enhance the security of the 
database files. The files containing statements to be inter- document as it is communicated across the Internet, the 
preted by the client program are then downloaded to the operator of the system may choose to utilize a more secure 
appropriate terminals, and the database files containing 30 physical connection between the device 420 and the Web 
database language statements are stored on the system server 12, To obtain this alternative connection, the PAY- 
executing the CGI 28. MENT command for the METHOD attribute is preferably 

Alternatively, the editor of the present invention may used. One form of the PAYMENT command is for a mer- 

parse integrated statements which are segregated into source chant's terminal and the other is for a consumer's terminal, 

code statements for first and second processors, such an 35 In either terminal, the client program which supports the 

editor further includes a compiler to generate executable extended capability HTML operates independently but 

code for each processor and, if the processors execute co-resident in memory with a certified bank card authoriza- 

differing source code, a compiler for each source code tion and capture application, which may be provided by a 

language. The executable code may then be downloaded to financial institution or a bank card processor, 

the respective processors for execution. 40 For the form of the command shown in FIG. 13B, the 

More specifically, the editor preferably places the data- client program in the merchant terminal suspends its execu- 

base statements for one of the transactions of the preferred tion and passes the terminal identifier, stored locally, which 

embodiment in a file identified by the database name fol- identifies the merchant's account and the consumer account 

lowing SQL in FIG. 12. The attributes and tags forming the information read via a magnetic stripe reader or the like, to 

HTMLstatementsforoneof the transactions of the preferred 45 the bank card application. The bank card application com- 

embodiment are placed in a file generally denoted as municates this information via a PSTN 424 or the like to a 

<htmLfile>.HTM. The name <html_file> is a name which transaction processor 422. The processor 422 authorizes or 

identifies one of the transactions. Where SQL statements are denies the transaction and, if authorized, a printer at the 

in the fields of the integrated statements shown in FIGS, 14 merchant terminal prints a purchase agreement which the 

to 23B, the string "<html_file>.SQL" is substituted as the 50 consumer may execute to complete the transaction, 

database name in the statements of the <html_file>.HTM In response to a HTML file having a FORM with an 

file. When the CGI executable file is initiated and parses the ACTION attribute equal to an executable file name for a 

returning forms, the returned data is placed in the corre- bank card application program or the like, a METHOD 

sponding "<htmt_file>.SQL" file which is passed to the attribute with a field value of PAYMENT, and an INPUT tag 

application program as a command line argument. In this 55 with a TYPE attribute of LOCAL_NAME which identifies 

manner, an abbreviated form for the SQL commands may be a deposit only account supplied by a merchant (as shown in 

communicated over the open network between the client and FIG. 13C), the client program is suspended and control is 

CGI and the CGI may be able to expand those abbreviated transferred to the bank processing application. The bank 

SQL commands into the appropriate SQL commands which processing application then uses a modem or ISDN D 

the application program requires to manipulate the ODBC 60 channel using T3 POS protocol or the like to connect to a 

database. secure packet network 424 to connect in a virtual point-to- 

To effectuate a transaction, for example, an operation at a point manner with a payment processor through a PSTN 

terminal with non-standard I/O devices may activate a network or the like. This physical connection provides an 

terminal file with a hot key or other action. In processing the additional security element to the encrypted data for the 

activated file, the client program may acquire data which is 65 transaction of account information, PIN numbers encrypted 

stored in a local variable or accessible through a non- by PIN pads provided at the consumer site, and other 

standard I/O device. This data may then be stored in a sensitive information. The bank processor 422 may submit 
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remittance data to the merchant, via the Web or otherwise. 
After receiving the remittance data, the merchant may ship 
the product to the consumer. Thus, in this manner, the I/O 
device may communicate with a plurality of Web servers to 
"shop" for a best price, delivery date, or other relevant 
information for selecting a preferred transaction, and then 
execute the PAYMENT method to utilize a more secure 
physical communication connection and data security 
devices to consummate the financial elements of the trans- 
action with less risk and costs for the merchant, consumer, 
and bank processor. 

The preferred integrated HTML/SQL statements which 
support a card initiated payment authorization and capture 
transaction are shown in FIG. 14. A first file 500 includes 
statements which identify the URL database from which the 
non-standard I/O device seeks authorization for a transac- 
tion. The prompts to the operator to enter the account 
number and amount of the transaction are supported by the 
INPUT tags which read the second track of the magnetic 
stripe reader to accept a number of up to 40 characters and 
assign that information from that track to a variable, and to 
input the up to 8 characters from the keyboard or the like into 
a variable called AMOUNT. The INPUT tag with the TYPE 
attribute of AUTOSUBMIT returns the form to the server for 
processing in accordance with the method defined in the 
returned form. As shown in FIG. 14, that METHOD state- 
ment causes CGI 28 to incorporate returned data into SQL 
commands which query the database as to whether the 
subfield of the track 2 data representing the account number 
is present in the authorization table of the database. If the 
data is not present, then a new record is inserted into a table 
labeled "log_table". The new record consists of the account 
number and the amount returned in the FORM. Based upon 
the results of this processing, the application program sup- 
plies the data fields to the FORM which will be returned to 
the client program for printing the transaction record. That 
file 510 is shown in FIG. 14. The ACTION attribute TO 
PRINTER and the POST METHOD causes the data in the 
next eight lines to be directed to the printer coupled to the 
non-standard I/O device for printing the transaction form. 
The customer may then execute the printed form to complete 
the transaction. If the transaction is declined or an error is 
otherwise encountered, the file 520 is used to return a denial 
to the client program. 

In a similar manner, the preferred integrated statements 
for a bar code order input with card-initiated payment 
authorization is shown in FIG. 15. The file 550, supported by 
the present invention which implements the transaction 
request, is again directed to the proper database by the 
ACTION attribute. The necessary customer information 
such as name and address may be input through a standard 
keyboard. The HTML command in the present invention 
also permits the form to receive the bar code, unit price, and 
credit card information in a manner similar to that discussed 
above for the magnetic card reader. Once this information is 
returned to the server and CGI interface, it is processed by 
the application program in accordance with the METHOD 
identified in the returned form. The method of HTML file 
550 also creates a database order_table having the infor- 
mation shown in the method. Again, if the transaction is 
approved, the data for the order and customer acceptance of 
the order is provided in HTML file 555, which is directed by 
the ACTION attribute to the printer at the non-standard I/O 
device. If the account number is not in the authorization 
database, the authorization declined or error response is 
provided in correspondence with the statements in file 560. 

In a similar manner, FIGS. 16-22 show the integrated 
statements for a transaction request, authorization response, 
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or authorization declined response files for key input order 
with secure payment transaction (FIG. 16), a smart card- 
debit (Type 1) transaction (FIG. 17 A), a smart card debit 
(Type 2) transaction (FIG. 17B), a debit card transaction 
(FIG. 18), a check verification transaction (FIG. 19), a 
customer frequency transaction (FIG. 20), an item search 
transaction for which there is no denial (FIG. 21), retail store 
end of day reporting (FIG. 22) and a store reporting an 
e-mail transaction (FIG. 23). 

While the present invention has been illustrated by the 
description of a preferred and alternative embodiments and 
processes, and while the preferred and alternative embodi- 
ments and processes have been described in considerable 
detail, it is not the intention of the applicant to restrict or in 
any way limit the scope of the appended claims to such 
15 detail. Additional advantages and modifications will readily 
appear to those skilled in the art. For example, rather than 
expanding HTTP to support non-standard I/O devices, the 
FTP, POP, SMTP, TELNET or other protocols may be 
expanded in like manner to couple non-standard I/O devices 
to the Internet. Similarly, the preferred implementation of 
the present invention supports a variety of non-standard I/O 
devices and I/O operations. An Internet protocol may be 
constructed in accordance with the principles of the present 
invention to support only selected I/O devices or operations 
disclosed in the present application. The invention in its 
broadest aspects is therefore not limited to the specific 
details, preferred embodiment, and illustrative examples 
shown and described. Accordingly, departures may be made 
from such details without departing from the spirit or scope 
of applicant's general inventive concept. 
What is claimed is: 

1. A method for communicating between a client program 
controlling in a non-standard input/output (I/O) device and 
a server over an open network comprising: 

activating a non-standard I/O device to assign data 
obtained by a non-standard I/O device to a variable 
name in a file comprised of extended open network 
protocol statements; and 
sending a file having said assigned data to a server to 
perform a data operation in accordance with said 
extended open network protocol statements. 

2. The method of claim 1 further comprising: 
identifying in one of said extended open network protocol 

statements an I/O operation for said non-standard I/O 
device to obtain said data for said assignment. 

3. The method of claim 1 further comprising: 
identifying a processing method for said data operation 

with said assigned data. 

4. The method of claim 1 further comprising: 
receiving a file comprised of extended open network 

protocol statements generated by said server from said 
data operation; and 
performing a data operation with said non-standard I/O 
device in accordance with at least one of said generated 
extended open network protocol statements in said 
received file. 

5. The method of claim 4 wherein said data operation is 
performed by executing an executable file identified by one 
of said generated extended open network protocol state- 
ments in said received file. 

6. A method for communicating between a client program 
controlling a non-standard input/output (I/O) device and a 
server over an open network comprising: 

generating a file comprising extended open network pro- 
tocol statements, at least one of which identifies a data 
operation for obtaining data from a non-standard I/O 
device; and 
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sending said file to a client program controlling said 
non -standard I/O device. 

7. The method of claim 6 further comprising: 
receiving data obtained by said non-standard I/O device 

performing said identified data operation. 

8. The method of claim 7 further comprising: 
performing a data operation with said data received from 

said non-standard I/O device; 

generating extended open network protocol statements 
from said data operation; and 

sending a file comprising said generated extended open 
network protocol statements to a client program con- 
trolling said non-standard I/O device. 

9. The method of claim 8 wherein said data operation 
identification is achieved by identifying an executable file 
name in one of said extended open network protocol state- 
ments. 

10. A system for communicating between a client pro- 
gram controlling a non-standard input/output (I/O) device 
and a server over an open network comprising: 

means for activating a non-standard I/O device to assign 
data obtained by a non-standard I/O device to a variable 
name in a file comprising extended open network 
protocol statements; and 

means for sending a file having said assigned data to a 
server to perform a data operation. 

11. The system of claim 10 further comprising: 
means for identifying in one of said extended open 

network protocol statements an I/O operation for said 
non-standard I/O device to obtain said data for said 
assignment. 

12. The system of claim 11 further comprising: 
means for identifying a processing method for said data 

operation with said assigned data. 
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13. The system of claim 11 further comprising: 
means for receiving a file comprising extended open 

network protocol statements generated by said server 
from said data operation; and 
means for performing a data operation at said non- 
standard I/O device in accordance with at least one of 
said generated extended open network protocol state- 
ments in said received file. 

14. The system of claim 13 further comprising: 

an executable file for performing said data operation, said 
executable file being identified by one of said generated 
extended open network protocol statements in said 
received file. 

. 15. A system for communicating between a client pro- 
gram controlling a non-standard input/output (I/O) device 
and a server over an open network comprising: 
means for generating a file comprising extended open 
network protocol statements, at least one of which 
i identifies a data operation for obtaining data from said 
non-standard I/O device; and 
means for sending said file to a client program controlling 
said non-standard I/O device. 

16. The system of claim 15 further comprising: 

; means for receiving data obtained by said non-standard 
I/O device performing said data operation. 

17. The system of claim 16 further comprising: 
means for performing a data operation with said data 

received from non-standard I/O device; 
means for generating extended open network protocol 

statements from said data operation; and 
means for sending a file comprising said generated 

extended open network protocol statements to a client 
; program controlling said non-standard I/O device. 

18. The system of claim 17 wherein said means for 
performing a data operation is an executable file. 

***** 
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